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'‘Maritime  Domain  is  all  areas  and  things  of,  on,  under, 
relating  to,  adjacent  to,  or  bordering  on  a  sea,  ocean,  or 
other  navigable  waterway,  including  all  maritime-related 
activities,  infrastructure,  people,  cargo,  and  vessels  and 
other  conveyances.  ” 

"Maritime  Domain  Awareness  (MDA)  is  the  ejfective  un¬ 
derstanding  of  anything  associated  with  the  maritime  do¬ 
main  that  could  impact  the  security,  safety,  economy,  or 
environment  of  the  United  States. 

"Global  Maritime  Community  of  Interest  (GMCOI)  in¬ 
cludes,  among  other  interests,  the  federal,  state,  and  local 
departments  and  agencies  with  responsibilities  in  the  mari¬ 
time  domain.  Because  certain  risks  and  interests  are  com¬ 
mon  to  government,  business,  and  citizen  alike,  community 
membership  also  includes  public,  private  and  commercial 
stakeholders,  as  well  as  foreign  governments  and  interna¬ 
tional  stakeholders.  ” 

—  National  Plan  to  Achieve  Maritime  Domain  Awareness 
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Background 


Information  sharing  is  a  foundational  tenet 
of  Maritime  Domain  Awareness  (MDA). 
Currently,  identical  information  is  collected 
and  stored  by  multiple  agencies  and  organi¬ 
zations.  However,  these  agencies  are  often 
unaware  that  similar  information  is  available 
from  other  organizations,  or  they  are  aware 
but  unable  to  share  this  information  with  one 
another  because  information  sharing  stan¬ 
dards  currently  do  not  exist.  Similarly,  agen¬ 
cies  with  relevant,  related,  or  complemen¬ 
tary  information  are  unable  to  combine  their 
data  to  achieve  greater  levels  of  situational 
awareness. 

MDA  is  being  implemented  within  the  con¬ 
text  of  national  information  and  data  sharing 
guidance.  This  guidance  includes  Execu¬ 
tive  Order  13388  and  the  National  Strategy 
for  Information  Sharing  (references  (k)  and 
(i)).  The  National  Strategy  for  Information 
Sharing,  although  broader  in  scope  than  just 
MDA  and  focused  on  terrorist  information, 
establishes  guiding  principles  and  founda¬ 
tional  elements  for  information  sharing  on  a 
national  level.  Many  other  policies,  guidance 
documents,  strategies,  and  plans  (see  Appen¬ 
dix  A)  help  set  and  shape  the  direction  of  in¬ 
formation  sharing  for  the  Global  Maritime 
Community  of  Interest  (GMCOI)  and  are 
discussed  throughout  this  strategy.  They  play 
a  major  role  in  establishing  mechanisms  for 
collaborating  and  enabling  an  aligned  transi¬ 
tion  to  the  desired  information  sharing  state 
for  the  GMCOI. 

The  National  Concept  of  Operations  for 
Maritime  Domain  Awareness  (MDA  CON- 
OPS)  (reference  (c))  describes  this  desired 
state  as  an  environment  in  which  the  GMCOI 
embraces  and  achieves  the  common  objec¬ 
tive  of  obtaining  and  sharing  information  as 


a  mechanism  to  increase  the  safety,  security, 
and  economic  prosperity  of  the  United  States 
in  the  maritime  domain. 

The  MDA  CONOPS  outlines  how  the  Feder¬ 
al  Government  will  organize  to  achieve  mari¬ 
time  domain  awareness.  It  creates  a  federal 
interagency  structure  that  includes  an  MDA 
Stakeholder  Board  to  coordinate  and  align 
MDA  policies.  In  addition,  the  MDA  CON- 
OPS  creates  four  enterprise  hubs.  Each  of 
these  hubs  is  responsible  for  coordinating  in¬ 
formation  sharing  among  the  multiple  agen¬ 
cies  and  organizations  within  each  MDA  in¬ 
formation  pillar;  vessels,  cargo,  people,  and 
infrastructure. 

An  additional  hub,  the  Architecture  Man¬ 
agement  Hub,  was  established  by  the  MDA 
CONOPS  to  design  and  manage  the  overall 
enterprise  architecture  needed  to  facilitate 
net-centric  sharing  of  maritime  information 
among  the  GMCOI  as  described  in  the  MDA 
CONOPS.  This  architecture  will  provide  the 
standards  and  processes  that  will  allow  the 
four  enterprise  hubs,  and  any  other  maritime 
community  member,  to  exchange  informa¬ 
tion  and  services. 

The  MDA  CONOPS  identifies  a  lead  agency 
or  department  for  each  of  the  four  enterprise 
hubs  and  the  Architecture  Management  Hub. 
The  Department  of  the  Navy  (DON)  is  the  ex¬ 
ecutive  agent  for  the  Department  of  Defense 
for  MDA  and  has  been  designated  as  the  lead 
department  for  the  Architecture  Management 
Hub.  The  DON  has  further  delegated  this  re¬ 
sponsibility  to  the  Department  of  the  Navy 
Chief  Information  Officer  (DON  CIO). 
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Purpose  &  Organization  of  this  Document 


■  t 


This  document  provides  an  initial  high- 
level  strategy  for  carrying  out  the  re¬ 
sponsibilities  of  the  national  Maritime  Do¬ 
main  Awareness  Architecture  Management 
Hub  to  deliver  a  standards  based  service 
oriented  architecture  that  will  align  MDA 
capabilities. 

It  outlines  key  goals  of  the  MDA  Architec¬ 
ture  Management  Hub  and  how  the  hub  will 
build  on  previous,  current,  and  emerging 
initiatives  across  the  Federal  Government. 


A  discussion  of  necessary  governance  in 
the  context  of  the  MDA  Architecture  Man¬ 
agement  Hub  follows.  Subsequently,  high- 
level  strategies  for  the  overall  MDA  enter¬ 
prise  architecture,  as  well  as  strategies  for 
key  tenets  of  net-centric  information  shar¬ 
ing  (data  standards  and  information  assur¬ 
ance)  are  included.  Finally,  this  document 
will  address  the  resource  implications  for 
development  and  implementation  of  the 
architecture. 
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The  goal  of  the  Architecture  Manage¬ 
ment  Hub  is  to  provide  a  blueprint  to 
develop  a  net-centric,  information  sharing 
environment,  in  which  data  from  dispa¬ 
rate  sources  and  security  domains  will  be 
discoverable,  accessible,  understandable, 
fused,  and  usable,  with  appropriate  infor¬ 
mation  assurance,  to  enable  user  defined 
and  common  operational  pictures.  This 
blueprint  will  guide  departments  and  agen¬ 
cies  in  their  development  of  capabilities  to 
enable  MDA. 

The  principal  characteristic  of  the  MDA  en¬ 
terprise  architecture  is  that  it  will  be  action¬ 
able.  As  an  actionable  architecture,  it  will: 


•  Inform  relevant  investment  decisions. 

•  Translate  stakeholders’  capability 
needs  into  requirements  that  can  be 
engineered. 

•  Drive  the  design  of  services,  appli¬ 
cations,  and  systems  based  on  those 
requirements. 

•  Support  the  selection  of  technology  that 
fulfills  capability  needs. 

•  Provide  a  formal  basis  for  validating 
solutions  against  the  originally  identi¬ 
fied  capability  needs. 


Vessel  Positions  in  the  Mediterranean  Sea 
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Building  on  Current  Initiatives 


Interagency  involvement  in  the  develop¬ 
ment  of  the  architecture  will  be  critical 
to  obtaining  support  for,  and  use  of,  the  ar¬ 
chitecture.  The  authority  to  direct  MDA 
stakeholders  to  publish  data  and  make  ser¬ 
vices  available  resides  within  the  compo¬ 
nents  and  agencies  themselves.  As  a  result, 
articulating  the  benefits  of  a  networked, 
service-oriented  architecture  (SOA)  and 
demonstrating  early  accomplishments  will 
be  critical  to  the  long  term  success  of  the 
effort.  Development  of  the  architecture 
will  proceed  in  an  incremental  fashion  with 
new  users  and  services  added  over  time,  in¬ 
cluding  those  from  state  and  local  govern¬ 
ments,  the  private  sector,  and  international 
partners. 


National  Plan  to  Achieve 
Maritime  Domain  Awareness 


National  MDA  Interagency  National  Concept  of 

Investment  Strategy  &  Operations  for  Maritime 

Supporting  Documents  Domain  Awareness 


MDA  Implementation  Team  Family  of  Documents 


The  efforts  of  the  Architecture  Management 
Hub  will  build  on  earlier  accomplishments 
of  the  MDA  Implementation  Team  and  its 
associated  work  groups.  In  2007  the  MDA 


Implementation  Team  established  an  on¬ 
going  national  MDA  organizational  struc¬ 
ture  through  the  MDA  CONOPS.  The  MDA 
Implementation  Team  also  used  a  four-step 
capability-based  assessment  process  to 
document  initial  requirements  and  exist¬ 
ing  capability  gaps  for  MDA.  These  docu¬ 
ments  include:  the  Interagency  Require¬ 
ments  Analysis  (reference  (e)).  Interagency 
Needs  Analysis  (reference  (f)).  Interagency 
Capabilities  Document  (reference  (g)),  and 
Interagency  Investment  Strategy  (reference 
(d)).  These  documents  identify  15  critical 
capability  gaps  and  the  tasks  required  to  fill 
them.  Of  these  tasks,  the  following  three 
relate  to  net-centric  information-sharing: 

•  Enable  network  access  to  all  designated 
nodes  across  the  GMCOI. 

•  Implement  Information  Assurance  (lA) 
and  Cross  Domain  Security  procedures 
across  the  GMCOI. 

•  Establish  National  MDA  data  standards 
and  data  strategy  across  the  GMCOI. 

These  tasks,  along  with  the  recommended 
solutions,  will  provide  the  initial  priorities 
for  the  MDA  enterprise  architecture. 

The  MDA  Interagency  Core  Architecture 
Document  (I  AC  A)  (reference  (h)),  devel¬ 
oped  as  part  of  this  work,  provided  a  pre¬ 
liminary  look  at  both  “as-is”  and  “to-be” 
elements  of  an  interagency  MDA  enter¬ 
prise  architecture.  The  I  AC  A  development 
process  focused  on  identifying  existing,  or 
“as-is”  interagency  relationships  and  cur¬ 
rent  MDA  capabilities  and  gaps.  This  de- 
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velopment  process  also  identified  possible 
courses  of  action  for  agency  and  depart¬ 
mental  decision  makers  to  close  current  ca¬ 
pability  gaps  as  part  of  the  “to-be”  architec¬ 
ture  efforts. 

Within  the  MDA  community,  other  initia¬ 
tives  are  underway  to  develop  net-centric 
capabilities.  Ground  breaking  efforts,  such 
as  the  MDA  Data  Sharing  Community  of 
Interest  (DS  COI),  have  led  the  way  in  de¬ 
veloping  SOA  capabilities  within  the  MDA 
community.  The  goal  of  these  efforts  has 
been  to  make  maritime  data  discoverable 
(easy  to  find),  accessible,  understandable, 
and  usable  for  a  variety  of  users,  including 
those  who  previously  could  not  obtain  and 
make  use  of  the  data.  The  MDA  DS  COI 
has  made  data  and  services  available  for 


use  by  other  applications  using  DoD’s  Net- 
Centric  Enterprise  Services  and  has  provid¬ 
ed  an  interface  for  the  unanticipated  user 
via  a  Google  Maps  Mediation  Service. 

The  Office  of  Naval  Intelligence  is  using  a 
phased  approach  to  transition  and  transform 
the  Integrated  Maritime  Intelligence  Archi¬ 
tecture  (IMA)  to  an  enterprise  architecture 
that  optimizes  functional  and  technological 
capabilities  to  enable  seamless  and  scalable 
access  to  an  integrated  global  maritime  in¬ 
telligence  domain.  The  IMA  will  imple¬ 
ment  a  SOA  approach  “for  organizing  and 
(re)using  enterprise  services  to  support  in¬ 
teroperability  between  National  Maritime 
Intelligence  Center  enterprise  data  assets 
and  applications,  and  established  data  shar¬ 
ing  and  interoperability  environments  with 


MDA  DS  COI 


meaiaiion 

Service 


Subscription 

Request 


NCES  Messaging  Service 


Messages  Recieved 
(In  COI  Vocab) 


Messages  Recieved 
(In  COI  Vocab) 


Subscription 

Request 


HSIN  Enterprise  Unanticipated  (Authorized)  User 


8 


Department  of  the  Navy  |  Chief  Information  Officer 


DoD,  federal,  and  Coalition  partners”  (ref¬ 
erence  u). 

The  National  Oceanographic  and  Atmo¬ 
spheric  Administration  (NOAA)  is  leading 
an  effort  to  develop  a  coordinated  national 
network  of  ocean,  coastal,  and  Great  Lakes 
observation  capabilities  known  as  the  Inte¬ 
grated  Ocean  Observing  System  (lOOS). 
lOOS  represents  a  national  partnership  of 
17  federal  agencies  and  11  regional  associ¬ 
ations  sharing  responsibility  for  the  design 
and  operation  of  the  system.  Once  com¬ 
pleted,  lOOS  will  integrate  oceanographic 
observation  systems  from  throughout  the 
federal,  state,  and  local  governments,  as 
well  as  the  scientific  and  academic  commu¬ 
nities.  lOOS  has  already  made  tremendous 
strides  sharing  maritime  information  across 
widely  dispersed  agencies  and  organiza¬ 
tions  that  will  greatly  benefit  the  Architec¬ 
ture  Management  Hub  effort. 

Of  particular  note  is  the  interagency  work 
being  accomplished  for  the  Federal  Infor¬ 
mation  Sharing  Environment  (ISE).  Al¬ 
though  the  ISE  is  primarily  concerned 
with  sharing  terrorist  related  information, 
their  effort,  “...aligns  and  leverages  ex¬ 
isting  information  sharing  policies,  busi¬ 
ness  processes,  technologies,  systems,  and 
promotes  a  culture  of  information  sharing 


through  increased  collaboration.”  These 
same  areas  must  be  aligned  to  form  a  cohe¬ 
sive  enterprise  architecture  for  MDA. 


The  Architecture  Management  Hub  will 
build  on  the  successes  of  these  efforts, 
while  encouraging  other  successful  MDA 
efforts  to  integrate  into  the  net-centric  en¬ 
vironment.  Many  current  efforts  provide  a 
tremendous  capability,  but  exchange  infor¬ 
mation  in  a  point-to-point  manner  and  do 
not  benefit  the  broader  maritime  commu¬ 
nity.  Once  these  capabilities  are  migrated 
to  a  SOA,  their  data  and  services  can  be  re¬ 
used  and  made  available  to  any  authorized 
user  as  necessary  to  enable  MDA. 

These  various  efforts  are  being  developed 
and  fielded  without  a  unifying  architecture 
to  form  a  cohesive  information  sharing  en¬ 
vironment  that  can  benefit  all  partners  in 
the  GMCOI.  The  Architecture  Manage¬ 
ment  Hub  will  align  these  and  other  efforts, 
identify  and  catalogue  relevant  associated 
systems,  and  leverage  the  standards  and 
processes  that  already  exist.  This  will  help 
to  establish  a  comprehensive  current  state 
architecture  for  the  federal  efforts  related  to 
MDA.  Based  on  this  work,  transition  and 
implementation  plans  will  be  developed  to 
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achieve  the  desired  end-state  MDA  enter¬ 
prise  architecture. 

As  the  Architecture  Management  Hub  ma¬ 
tures,  metrics  and  measures  of  effective¬ 
ness  will  be  developed  to  ensure  sufficient 
progress  is  being  made  toward  its  objec¬ 
tives.  Various  existing  operational  exercis¬ 
es  will  be  used  to  evaluate  the  ability  of  us¬ 
ers  to  exchange  information.  A  concerted 
outreach  effort  will  also  be  undertaken  to 
inform  and  educate  potential  users  on  the 
processes  developed  and  how  to  participate 
in  the  network. 
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Governance  Strategy 


-[^fi 


As  the  lead  for  the  Architecture  Man¬ 
agement  Hub,  the  DON  CIO  will  work 
with  the  existing  governance  structure  es¬ 
tablished  by  the  MDA  CONOPS,  and  may 
need  to  leverage  other  governance  bodies, 
such  as  the  Federal  CIO  Council.  In  this 
role,  the  DON  CIO  will  focus  on  coordinat¬ 
ing  the  MDA  enterprise  architecture  efforts 
and  developing  appropriate  policies,  proce¬ 
dures,  and  standards. 


Committee,  and  is  responsible  for  MDA 
policy  alignment,  synergy,  and  issue  reso¬ 
lution.  The  MDA  Stakeholder  Board  will 
provide  executive  oversight  of  the  Architec¬ 
ture  Management  Hub.  The  four  enterprise 
hubs  (Vessel,  Cargo,  People,  and  Infra¬ 
structure)  report  and  provide  recommenda¬ 
tions  to  the  Stakeholder  Board  through  its 
coordinating  body,  the  Information  Sharing 
Sub-Committee. 


Federal  interagency  MDA  efforts  are  co¬ 
ordinated  by  the  MDA  Stakeholder  Board, 
which  is  co-chaired  by  the  Director,  Global 
Maritime  and  Air  Intelligence  Integration 
(GMAII)  and  Director,  Global  Maritime 
Situation  Awareness  (GMSA).  The  Stake¬ 
holder  Board  is  a  coordinating  body  under 
the  Maritime  Security  Policy  Coordination 


The  DON  CIO  will  lead  and  manage  the  Ar¬ 
chitecture  Management  Hub.  Each  depart¬ 
ment,  agency,  and  organization  with  mem¬ 
bership  on  the  MDA  Stakeholder  Board 
will  also  be  represented  on  the  Architecture 
Management  Hub. 

These  governance  structures  will  be  lever¬ 
aged  to  govern  the  necessary  processes  and 
service  level  agreements  requisite  for  effi- 


National  MDA  Governance  Structure 
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individual  agencies  are  aligned  to  achieve 
MDA  objectives. 

The  Architecture  Management  Hub,  work¬ 
ing  with  the  IS  SC,  will  identify  policy  bar¬ 
riers  as  well  as  cultural,  procedural,  and 
technological  barriers  to  information  shar¬ 
ing.  Barriers  include  issues  such  as  the 
lack  of  interagency  coordination/alignment 
of  information  sharing  policies,  and  a  re¬ 
luctance  by  some  data  providers  to  provide 
detailed  information. 

To  effectively  execute  the  roles  and  re¬ 
sponsibilities  of  the  Architecture  Manage¬ 
ment  Hub,  the  DON  CIO  will  establish 
focus  teams  within  the  hub  to  concentrate 
on  key  aspects  of  the  MDA  enterprise  ar¬ 
chitecture.  Focus  team  leads  will  be  des¬ 
ignated  by  the  DON  CIO  and  membership 
will  be  composed  of  representatives  from 
throughout  the  Federal  Government,  prin¬ 
cipally  from  organizations  composing  the 
GMCOI.  Active  participation  by  individu¬ 
als  with  knowledge  of  information  sharing 


efforts  within  their  own  agency  and  the  ex¬ 
pertise  to  effectively  assist  the  focus  team 
on  its  assigned  task  is  critical.  Initial  focus 
teams  will  include:  Standards,  Information 
Assurance,  Technical,  and  Process. 

The  Standards  Focus  Team  will  develop 
those  standards  (schema/vocabulary,  meta¬ 
data,  etc.)  that  will  allow  users  to  publish 
data  to  the  network  and  make  it  available 
to  other  users  (subscribers).  These  stan¬ 
dards  will  incorporate  appropriate  exist¬ 
ing  and  emergent  standards  (e.g.,  UCore, 
NIEM,  etc.)  or  procedures  for  mediation  as 
necessary. 

The  Information  Assurance  Focus  Team 
will  develop  methods  for  protecting  infor¬ 
mation  published  to  the  network,  including 
methods  to  ensure  only  authorized  users 
have  access  to  information  (confidentiality), 
information  cannot  be  manipulated  without 
authority  (integrity),  only  authorized  infor¬ 
mation  is  published  to  the  network  (authen- 


Architecture 
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ticity),  and  information  is  available  when 
needed  (availability). 

The  Technology  Focus  Team  will  identify 
and  recommend  technical  solutions  to  en¬ 
able  net-centric  information  sharing  within 
the  GMCOI. 

The  Process  Focus  Team  will  document 
the  MDA  operational  processes  described 
in  the  MDA  CONOPS  and  other  documen¬ 
tation.  They  will  also  develop  standard, 
non-technical  processes  and  procedures  for 
publishing  and  subscribing  information  to 
and  from  the  network. 


Each  focus  team  will  in  effect  be  develop¬ 
ing  a  part  of  the  overall  MDA  enterprise 
architecture.  To  ensure  synthesis  of  these 
parts  and  create  an  integrated,  cohesive, 
and  actionable  enterprise  architecture,  an 
Architecture  Coordination  Board  will  be 
established.  This  board  will  be  responsible 
for  developing  and  recommending  an  MDA 
enterprise  architecture  description  from  the 
recommendations  of  the  focus  teams. 


MDA  Architecture  Management  Hub  Strategy 


13 


r\ 


Iterative  Approach 


An  iterative  approach  will  be  used  to  de¬ 
sign  the  MDA  enterprise  architecture. 
In  this  way  users  of  the  architecture  can  re¬ 
alize  early  benefits  during  the  design,  and 
continue  to  see  increased  utility  over  time. 
Each  of  the  Architecture  Management  Hub 
focus  teams,  guided  by  the  Architecture  Co¬ 
ordination  Board,  will  explore  topics  with¬ 
in  its  scope,  prioritize  and  select  issues  to 
address,  work  to  resolve  those  issues,  and 
evaluate  the  results  before  moving  on.  Fo¬ 
cus  teams  will  work  in  parallel  on  comple¬ 
mentary  issues  where  appropriate. 


Steps  in  the  Iterative  Process 


Discovery  of  Ongoing  Relevant  Efforts 

The  first  step  in  the  process  will  be  a  discov¬ 
ery  phase  in  which  the  focus  team  works  to 
understand  relevant  efforts  already  under¬ 
way.  Within  this  phase,  the  focus  team  will 
examine  various  aspects  of  these  efforts 
including  the  scope,  purpose,  intended  us¬ 
ers,  organizational  roles  and  relationships, 
domains/environments,  and  types  of  data/ 
information  to  be  exchanged  as  applicable. 
In  addition,  the  focus  teams  will  need  to  re¬ 
view  the  level  of  effort,  extent  of  capabili¬ 
ties,  status  of  deliverables,  and  schedule.  To 
some  extent,  initial  discovery  of  relevant 


efforts  has  already  been  ongoing. 

Prioritization 

After  building  an  understanding  of  the  oth¬ 
er  relevant  efforts,  each  focus  team  will 
prioritize  the  challenges  within  its  scope 
based  on  gap  analysis  and  input  from  the 
enterprise  hubs.  The  focus  teams  will  de¬ 
velop  a  prioritized  list  of  actionable  efforts 
to  choose  from,  including  potential  courses 
of  action. 

Selection 

Once  a  prioritized  list  is  developed  an  is¬ 
sue  will  be  chosen  for  the  focus  team  to 
resolve.  Guided  by  the  MDA  Stakeholder 
Board,  each  focus  team  will  select  the  best 
option  to  pursue  for  its  initial  work  from 
the  prioritized  list. 

Execution 

Based  on  the  selection  decision,  each  fo¬ 
cus  team  will  carry  out  its  work  to  execute 
the  selected  effort.  Ideally  each  focus  team 
will  work  on  one  issue  at  a  time  in  a  logi¬ 
cal  sequence,  but  parallel  efforts  may  be 
necessary. 

Evaluation 

Once  the  initial  effort  is  completed,  each 
focus  team  will  evaluate  the  results,  and 
with  the  assistance  of  the  Architecture  Co¬ 
ordination  Board,  incorporate  them  into 
the  architecture.  Following  this,  the  focus 
team  will  update  its  gap  analysis  and  plan 
for  the  next  iteration.  In  addition  the  focus 
team  will  develop  a  sustainment  plan  to  en¬ 
sure  the  longevity  of  the  solution  that  was 
developed. 
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The  principal  characteristic  of  the  MDA 
enterprise  architecture  is  that  it  will  be 
actionable.  This  enterprise  architecture  will 
be  developed  in  four  primary  parts: 

•  An  Information  Exchange  Model  fo¬ 
cused  on  enumerating  and  classifying 
the  information  exchanges  with  and 
within  the  GMCOI. 

•  A  Services  Model  focused  on  describ¬ 
ing  and  classifying  the  information  ser¬ 
vices  necessary  to  facilitate  the  infor¬ 
mation  exchanges. 

•  An  Operational  Model  focused  on  de¬ 
scribing  operational  nodes  and  pro¬ 
cesses  to  share  information  within  the 
GMCOI. 

•  An  Interoperability  Model  focused  on 
describing  standards  for  the  connection 
and  exchange  of  information  between 
information  services. 

Although  each  of  the  Architecture  Manage¬ 
ment  Hub  focus  teams  will  be  exploring  nu¬ 
merous  aspects  of  their  respective  domains 
and  producing  a  variety  of  architectural 
and  programmatic  insights,  their  collective 
products  will  be  integrated  by  the  Architec¬ 
ture  Coordination  Board  to  form  the  four 
primary  architectural  models  described  in 
this  section. 

Information  Exchange  Model.  The  key  to 
developing  an  actionable  MDA  enterprise 
architecture  is  a  complete  and  correct  un¬ 
derstanding  of  the  information  exchanges 
necessary  to  support  the  operations  and 


processes  described  in  the  MDA  CONOPS. 
This  is  accomplished  by  developing  an  in¬ 
formation  exchange  model  that  enumerates 
and  classifies  the  information  exchanges 
with  and  within  the  GMCOI. 

These  exchanges  will  include: 

•  Planned  exchanges  between  MDA  in¬ 
formation  pillars,  i.e.  vessels,  cargo, 
people,  and  infrastructure  pillars. 

•  Unplanned  or  unanticipated  exchanges 
between  MDA  information  pillars. 

•  Planned  and  unplanned  exchanges  be¬ 
tween  MDA  information  pillars  and 
external  entities,  e.g.  non-GMCOI  mis¬ 
sion  area  organizations. 

The  resulting  understanding  provides  the 
foundation  for  all  other  MDA  information 
sharing  architecture  development. 

Services  Model.  The  information  exchang¬ 
es  described  above  can  be  viewed  as  the 
provisioning  of  capabilities  among  and  by 
the  entities  composing  the  GMCOI.  Best 
practices  in  architecture  dictate  the  use  of  a 
service-oriented  model  to  describe  this  pro¬ 
visioning  of  capabilities.  In  other  words, 
emphasis  is  upon  services  as  the  providers 
of  capabilities  to  consumers.  This  is  ac¬ 
complished  by  developing  a  services  model 
focused  on  describing  and  classifying  the 
information  services  necessary  to  facilitate 
the  information  exchanges.  This  is  in  con¬ 
trast  to  traditional  approaches  to  informa¬ 
tion  systems  architecture  that  focus  on  the 
underlying  hardware  and  software  as  the 
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solution  to  capability  need.  The  develop¬ 
ment  of  a  services  model  implies  the  use 
of  an  architectural  style  known  as  Service- 
Oriented  Architecture  (SOA)  (see  Service- 
Oriented  Architecture  section  on  page  17). 


inputs  and  outputs  between  process  ele¬ 
ments  described  in  the  Operational  Model. 
The  Services  Model  results  from  the  deri¬ 
vation  of  automated  services  necessary  to 
facilitate  such  information  exchanges. 


Operational  Model.  Preparatory  to  under¬ 
standing  the  information  exchanges  and  re¬ 
lated  services  that  describe  the  provision¬ 
ing  of  capabilities  for  MDA  information 
sharing,  it  is  necessary  to  understand  the 
larger  operational  context  for  such  capabil¬ 
ities.  This  is  accomplished  by  developing 
an  operational  model  focused  on  describ¬ 
ing  operational  processes  and  associated 
nodes  for  sharing  information  within  the 
GMCOI. 

Information  sharing  is  the  result  of,  as  well 
as  the  enabler  of,  accomplishing  operation¬ 
al  processes.  The  Information  Exchange 
Model  results  directly  from  the  collective 


Interoperability  Model.  Architectural 
styles,  such  as  SOA,  depend  on  the  use  of 
standard  protocols  to  enforce  the  principles, 
practices,  and  patterns  composing  the  style. 
In  the  case  of  SOA,  these  protocols  stan¬ 
dardize  the  way  information  services  con¬ 
nect  and  exchange  information  via  service 
interfaces.  The  use  of  such  protocols  en¬ 
sures  interoperability  as  solution  elements 
are  developed  and  deployed  to  create  the 
MDA  enterprise  architecture.  This  is  ac¬ 
complished  by  developing  an  interoperabil¬ 
ity  model  focused  on  describing  standards 
for  the  connection  and  exchange  of  infor¬ 
mation  between  information  services. 
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The  following  diagram  provides  a  high  lev¬ 
el  outline  of  these  four  models  as  milestones 
to  achieve  the  “As-Is”  architecture  and  an 
initial  version  of  the  “To-Be”  architecture 

There  are  two  key  aspects  that  must  be 
considered  in  developing  the  above  mod¬ 
els.  The  first  is  the  employment  of  SOA 
principles,  practices,  and  patterns.  The  sec¬ 
ond  is  the  use  of  architecture  description 
artifacts  mandated  by  accepted  architecture 
frameworks.  The  following  discussion  ad¬ 
dresses  the  importance  of  these  consider¬ 
ations  in  creation  of  the  MDA  Enterprise 
Architecture. 

Service-Oriented  Architecture 
It  is  important  to  separate  the  issues  of  ser¬ 
vice-oriented  architecture  from  service-ori¬ 
ented  implementation  and  the  use  of  asso¬ 


ciated  technologies.  SOA  focuses  on  how 
to  design  the  provisioning  of  automated  ca¬ 
pabilities  and  the  interaction  of  architectur¬ 
al  entities  (i.e.  services)  that  provide  such 
capabilities.  Service-oriented  implementa¬ 
tion  focuses  on  the  design  of  technical  so¬ 
lutions  that  implement  automated  functions 
to  achieve  a  service-oriented  architecture. 
The  four  models  described  above  will  fo¬ 
cus  on  SOA,  but  an  effective  MDA  infor¬ 
mation  sharing  solution  will  also  require 
evaluation  and  development  of  technology 
for  service-oriented  implementation. 

The  Technology  Focus  Team  will  explore 
existing  infrastructure  available  to  the  GM- 
COI  in  search  of  capabilities  to  satisfy  the 
emerging  infrastructure  service  require¬ 
ments  described  in  the  services  and  infor¬ 
mation  exchange  models.  The  team  will 


Architecture  Coordination  Team 


Standards  Focus  Team 


I  Process  Focus  Team 


^  Technology  Focus  Team 
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identify  capability  gaps,  plan  for  solutions, 
and  develop  a  solution  architecture  that 
identifies  the  use  of  existing  and  needed 
technologies  to  achieve  the  MDA  enter¬ 
prise  architecture. 

From  a  SOA  point  of  view,  this  would  in¬ 
clude  evaluation  of  enterprise  service  in¬ 
frastructures  and  catalogs  of  available  ser¬ 
vices  resident  in  registries  and  repositories 
distributed  throughout  the  GMCOI.  It  is 
important  that  the  capabilities  available  via 
the  MDA  information  pillars  adhere  to  the 
interoperability  model  and  make  discover¬ 
able,  available,  and  usable  their  current  and 
future  information  services  to  satisfy  the 
services  and  information  exchange  models. 
Evaluation  and  mapping  of  current  capabil¬ 
ities  within  the  GMCOI  will  result  in  devel¬ 
opment  of  an  “as-is”  architecture  for  MDA 
information  sharing. 


Rather  than  architecting  and  constructing 
new  technical  solutions  to  achieve  a  “to- 
be”  MDA  enterprise  architecture,  existing 
capabilities  and  technology  will  be  feder¬ 
ated  to  create  new  capabilities.  Through  its 
focus  teams,  the  Architecture  Management 
Hub  will  identify  existing  architecture  fed¬ 
eration  approaches,  recommend  a  federa¬ 
tion  strategy,  and  transition  legacy  technol¬ 
ogy  to  a  federated  approach. 

Numerous  efforts  are  on  going  throughout 
the  Federal  Government  to  develop  core 
enterprise  infrastructure  and  services.  Core 
services  commonly  include  directory  and 
search  capability,  identity  management  ser¬ 
vices  and  attribute  stores,  security  services, 
mediation,  messaging,  and  collaboration. 

Exposing,  leveraging,  and  aligning  these 
services  will  be  critical  to  the  MDA  en¬ 
terprise  architecture.  The  challenge  to  the 


International  I  I  I  DHS  I  DOT  I  DOJ  I  Federal  I  State  &  Local  I  Industry 
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Common  Industry-based  Standards  and  Specifications 


Global  MDA  Data  Consumers 

Common  Standards  and  Specifications  to  Faciiitate  information  Sharing  Across  the  infrastructures 
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Architecture  Management  Hub  will  be  to 
federate  these  infrastructures  to  facilitate 
net-centric  information  sharing  between 
federal  departments  and  agencies.  Al¬ 
though  some  work  has  been  done  in  the 
field  of  federated  services,  most  notably  by 
the  Information  Sharing  Environment,  this 
is  basically  a  new  business  model.  Federat¬ 
ing  service  infrastructures  will  require  the 
federation  of  core  services  where  possible. 
For  example,  rather  than  develop  an  MDA 
metadata  registry  and  repository,  metadata 
registries  from  the  various  service  infra¬ 
structures  could  be  federated,  thus  allowing 
them  to  exchange  information  directly. 

The  challenge  for  the  Architecture  Man¬ 
agement  Hub  will  be  to  develop  a  repeat- 
able  process  to  federate  services  and  infra¬ 
structures.  The  Architecture  Management 
Hub  will  then  need  to  educate  members  of 
the  GMCOI  on  how  to  implement  these 
processes.  This  can  be  done  in  an  iterative 
approach  in  which  users  are  continually 
trained  as  they  are  added  to  the  network. 

Because  many  federal  departments  and 
agencies  do  not  yet  operate  in  a  net-centric 
SOA  environment,  an  additional  challenge 
for  the  Architecture  Management  Hub  will 
be  the  need  to  provide  methods  for  those 
agencies  to  publish  and  subscribe  data  and 
services  to  and  from  the  network. 

There  will  likely  be  some  core  services  for 
which  federation  is  not  an  optimal  solu¬ 
tion.  Selection  of  an  individual  agency  to 
provide  these  services  to  the  GMCOI  may 
be  required.  For  instance,  it  may  be  nec¬ 
essary  to  select  an  “implementation  agent” 


for  some  collaboration  services  to  support  a 
common  operational  picture  across  MDA. 

Architecture  Frameworks 
and  Descriptions 

Once  completed,  the  MDA  enterprise  ar¬ 
chitecture  must  be  presented  in  a  form 
commonly  used  by  and  understandable  to 
decision-makers,  reviewers,  and  architects 
of  other  efforts.  This  is  usually  accom¬ 
plished  through  the  use  of  an  architecture 
framework  -  a  framework  for  describing 
and  communicating  architectures.  Such 
a  framework  is  a  set  of  assumptions,  con¬ 
cepts,  values,  and  practices  that  constitutes 
a  way  of  viewing  an  architecture  reality. 
An  architecture  framework  provides  a  col¬ 
lection  of  patterns  for  creating  and  present¬ 
ing  architecture  descriptions. 

There  are  three  architecture  frameworks  of 
interest  in  the  development  of  the  MDA  en¬ 
terprise  architecture:  the  Federal  Enterprise 
Architecture  (FEA);  the  DoD  Architecture 
Framework  (DoDAF);  and  the  Information 
Sharing  Environment  Enterprise  Architec¬ 
ture  Framework  (ISE  EAF). 
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Most  non-DoD  federal  agencies  employ 
the  FEA  and  its  recent  extension,  the  Fed¬ 
eral  Segment  Architecture  Methodology 
(FSAM).  FEA  emphasizes  the  use  of  archi¬ 
tectural  element  taxonomies  expressed  as 
references  models  (e.g.  Business  Reference 
Model,  Data  Reference  Model,  Service 
Component  Reference  Model,  etc.).  To  en¬ 
sure  maximum  interagency  application,  the 
Architecture  Management  Hub  will  utilize 
the  Federal  Enterprise  Architecture  in  de¬ 
scribing  the  MDA  enterprise  architecture. 

DoD  commands,  services,  and  agencies, 
as  well  as  the  Coast  Guard,  employ  the 
DoDAF.  DoDAF  emphasizes  the  use  of  a 
variety  of  architectural  models  to  describe 
differing  perspectives  or  views  of  a  whole 
architecture.  DoDAF  provides  a  formal 
nomenclature  for  such  models.  Embedded 
within  the  FEA  is  the  idea  of  using  models 
to  express  architectural  elements  and  their 
relationships.  Although  FEA  and  DoDAF 
use  similar  models,  FEA  does  not  specify  a 
model  nomenclature. 
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The  challenge  to  the  Architecture  Manage¬ 
ment  Hub  will  be  to  integrate  the  use  of 
models  common  to  both  FEA  and  DoDAF 
within  the  higher-order  structure  of  the 
FEA’s  taxonomies  to  create  an  actionable 
architecture  description  for  the  MDA  enter¬ 
prise  architecture. 

While  the  FEA  and  the  DODAF  are  com¬ 
pliance  frameworks,  the  ISE  EAF  is  not 
vested  in  policy  as  required  for  compliance. 
Rather,  the  ISE  EAF  provides  constructs, 
or  patterns,  for  sharing  information  at  the 
federal  level. 

The  Information  Sharing  Initiative  ISE 
EAF  was  developed  by  the  PM-ISE.  The 
ISE  and  the  information  resources  construct 
developed  from  the  ISE  EAF,  will  link  ISE 
participants  (federal,  state,  local  and  tribal 
governments,  foreign  partners  and  allies, 
and  the  private  sector)  to  create  a  distrib¬ 
uted,  protected,  and  trusted  environment 
for  sharing  information.  The  ISE  EAF  will 
evolve  over  time  as  additional  business  pro¬ 
cesses,  information  flows  and  exchanges, 
services,  and  technologies  are  defined  and 
incorporated  into  the  ISE.  While  the  ISE 
EAF  was  developed  for  primary  use  as  a 
tool  for  anti-terrorism,  its  constructs  can  be 
used  to  enable  general  information  sharing 
within  the  Federal  Government. 
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Vision  for  Net-Centric  Information 
and  Services  Sharing 

Establishing  a  shared  vision  for  net-centric 
information  and  services  sharing  compels 
a  shift  from  “point-to-point”  interfaces  to  a 
“many-to-many”  exchange  of  data,  and  en¬ 
ables  many  users  and  applications  to  lever¬ 
age  the  same  information  and  services.  A 
key  objective  is  to  accelerate  decision  cy¬ 
cles  by  ensuring  that  the  right  data  is  avail¬ 
able  at  the  right  time,  in  the  right  place. 

Making  data  visible,  accessible,  under¬ 
standable,  and  trustable  are  the  cornerstones 
of  net-centric  information  sharing.  The  cre¬ 
ation  of  duplicative  data  and  redundant 
capabilities  often  results  from  consumers’ 
inability  to  locate,  access,  or  understand 
existing  data  assets,  or  trust  that  they  meet 
their  needs. 


The  purpose  of  establishing  data  standards 
is  to  facilitate  agile  information  sharing 


Federated  Core  Enterprise  Services  providing 
authorized  consumers  the  ability  to  discover,  access 
and  understand  shared  data,  products  and  services 


The  Ability  to  Publish  and  Subscribe 
is  Key  to  Infrastructure  Sharing 


across  the  MDA  community  of  data  pro¬ 
ducers  and  data  consumers. 

The  National  MDA  Architecture  Manage¬ 
ment  Hub’s  approach  to  data  standards  is 
to  leverage  existing  data  sharing  initiatives, 
best  practices,  and  lessons  learned;  identify 
information  exchanges;  identify  authori¬ 
tative  sources  of  data  as  necessary;  define 
data  quality  of  service  standards;  and  rec¬ 
ommend  common  vocabulary,  informa¬ 
tion  exchange,  and  registration  processes 
and  tools.  The  goal  of  this  approach  is  to 
provide  seamless  interoperability  across 
the  MDA  community  that  will  provide  a 
secure,  collaborative,  information-sharing 
environment. 

Reference  Information  and  Services 
Synchronization 

The  MDA  “as-is”  data  architecture  will  de¬ 
scribe  existing  maritime  data  sources,  pro¬ 
ducers,  consumers,  and  existing  informa¬ 
tion  exchanges  as  a  baseline  for  moving 
forward.  Identifying  existing  data  sharing 
initiatives,  best  practices,  lessons  learned, 
and  information  exchanges  are  critical  ear¬ 
ly  steps  to  creating  the  baseline.  This  base¬ 
line  will  assist  in  identifying  data  assets  that 
are  authoritative  sources  for  data,  as  well  as 
identifying  the  contexts  in  which  the  data 
is  authoritative.  In  situations  where  there  is 
more  than  one  authoritative  source,  depend¬ 
ing  on  how  the  data  is  used,  services  are 
needed  to  indicate  the  business  process  for 
which  the  authority  is  valid.  Ownership  and 
stewardship  of  data  sources  will  be  consid¬ 
ered  when  determining  authoritativeness. 
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A  web-accessible  registry  will  be  needed  to 
capture  and  manage  data  sources,  produc¬ 
ers,  and  consumers.  As  data  producers  reg¬ 
ister  their  data  assets  in  the  registry,  the  reg¬ 
istry  can  be  used  to  identify  authoritative 
sources  of  data  as  necessary,  reduce  and 
eliminate  duplicative  data  as  appropriate, 
identify  data  gaps  and  incompatibilities, 
and  align  data  naming,  design,  and  infor¬ 
mation  exchange  standards. 

Data  Quality 

Data  assets  can  be  trusted  only  if  their  con¬ 
tents  are  sufficiently  accurate  and  of  suf¬ 
ficiently  reliable  quality.  Assessing  and 
improving  data  asset  quality  is  important. 
Quality  of  service  standards  and  active 
stewardship  need  to  be  defined  and  coordi¬ 
nated  to  establish  and  maintain  the  quality 
and  relevance  of  authoritative  data  sources. 
The  Architecture  Management  Hub  will: 
develop  an  ongoing  process  for  auditing  the 
quality  of  data  assets  that  are  made  visible 
and  accessible;  develop  guidelines  for  data 
producers  and  consumers  to  ensure  that  the 
data  required  by  the  GMCOI  is  available, 
accurate,  complete,  and  interoperable;  pro¬ 
vide  a  single  joint  collaborative  forum  for 
coordination  of  MDA  data  architecture, 
data  quality,  and  metadata;  and  provide  a 
single  means  to  address,  resolve,  and  track 
data  issues. 

Quality  assertions  about  data  include  infor¬ 
mation  on  its  accuracy,  completeness,  or 
timeliness  for  a  particular  purpose.  For  ex¬ 
ample,  consumers  might  need  to  know  the 
age  of  the  data  to  determine  whether  it  is 
still  applicable,  or  they  might  need  to  know 


how  accurate  estimates  and  figures  within 
the  data  asset  are. 

Standard  Vocabulary  Methodology 

MDA  data  and  services  producers  and  con¬ 
sumers  comprise  a  collaborative  group  of 
users  who  must  exchange  information  in 
pursuit  of  their  shared  goals,  interests,  mis¬ 
sions,  or  business  processes.  To  facilitate 
this  information  exchange,  the  MDA  users 
need  a  shared  vocabulary  for  the  informa¬ 
tion  they  exchange.  The  Architecture  Man¬ 
agement  Hub  will  work  with  the  Cargo, 
Vessel,  People,  and  Infrastructure  hubs  to 
create  necessary  data  standards  and  a  shared 
vocabulary  to  facilitate  exchange  of  the  in¬ 
formation  within  and  among  the  hubs. 

The  National  Information  Exchange  Mod¬ 
el  (NIEM),  Universal  Core  (UCore),  and 
Maritime  Information  Exchange  Model 


Maritime 
Extension  to 
NIEM 


Universal 

Core 


1 


NIEM 


Notional  Representation  of  the  MIEM  as 
the  Maritime  Extension  to  the  NIEM 
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(MIEM)  are  reference  models  designed  to 
enable  a  level  of  interoperability  in  the  ex¬ 
change  of  information — for  the  sender  and 
receiver  of  information  to  share  a  common, 
unambiguous  understanding  of  the  mean¬ 
ing  of  that  information.  Each  of  these  ref¬ 
erence  models  started  independently  but 
they  are  now  aligning  as  complementary 
initiatives  with  complementary  models. 

The  NIEM  “is  designed  to  develop,  dis¬ 
seminate,  and  support  enterprise-wide  in¬ 
formation  sharing  standards  and  processes 
across  the  whole  of  the  justice,  public  safe¬ 
ty,  emergency  and  disaster  management, 
intelligence,  and  homeland  security  enter¬ 
prise  at  all  levels  and  across  all  branches 
of  government”  (reference  (m).  The  NIEM 
represents  a  collaborative  partnership  of 
agencies  and  organizations  across  all  levels 
of  government  (federal,  state,  tribal,  and  lo¬ 
cal)  and  with  the  private  sector. 

The  NIEM  reference  model  includes  two 
categories  of  reusable  components:  core 
components  and  domain- specific  compo¬ 
nents.  The  NIEM’s  core  components  are 
further  classified  as  either  universal  or 
common.  Domain-specific  components 
are  understood  and  managed  by  a  specific 
community  of  interest.  Domain-specific 
components  can  extend  core  components 
and  must  conform  to  the  NIEM  naming 
and  design  rules.  Domains  are  organized 
to  facilitate  governance,  and  each  has  some 
measure  of  persistency.  Domains  tradition¬ 
ally  include  a  cohesive  group  of  data  stew¬ 
ards  who  are  subject  matter  experts  (SMEs), 
have  some  level  of  authority  within  the  do¬ 
mains  they  represent,  and  participate  in  the 


processes  related  to  harmonizing  conflicts 
and  resolving  data  component  ambiguities. 

MIEM  development  began  in  2006  to  sup¬ 
port  collaborative  tracking  of  vessels,  peo¬ 
ple,  and  cargo.  Also  beginning  in  2006,  but 
as  a  separate  initiative,  the  MDA  DS  COI 
was  formed  to  define  schemas  for  sharing 
sensor  data,  such  as  data  received  from  Au¬ 
tomatic  Identification  System  (AIS)  tran¬ 
sponders.  The  MDA  DS  COI  became  a 
beta  tester  of  the  MIEM  and  has  demon¬ 
strated  successful  modeling  and  sharing  of 
that  data.  The  strategy  for  implementing 
MDA  at  the  national  level  is  to  establish 
MIEM  as  the  maritime  domain  extension  to 
NIEM. 

UCore  is  an  interagency  initiative  accom¬ 
plishing  a  critical  functional  element  of  the 
National  Information  Sharing  Strategy-es¬ 
tablishing  an  information  exchange  speci¬ 
fication  and  implementation  profile.  This 
consists  of  a  vocabulary  of  most  commonly 
exchanged  concepts,  XML  representation 
of  the  concepts,  extension  rules  to  allow 
tailoring  to  specific  mission  areas,  secu¬ 
rity  marking  to  permit  controlled  access, 
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and  a  messaging  framework  to  package 
and  unpackage  the  content  consistently. 
UCore  Version  2.0  defines  a  small  num¬ 
ber  of  universally  understandable  concepts 
that  are  commonly  shared  and  understood 
among  all  domains.  Development  of  Ver¬ 
sion  2.0,  has  extended  beyond  the  “Where” 
and  “When”  of  Version  1 .0  to  include  the 
“Who”  and  “What”  components.  During 
the  alpha-testing  phase,  the  UCore  devel¬ 
opment  team  created  and  published  an  in¬ 
formation  exchange  specification  and  co¬ 
ordinated  approximately  20  risk  reduction 
pilots  conducted  by  various  organizations 
in  the  DoD,  Department  of  Homeland  Se¬ 
curity  (DHS),  Director  of  National  Intel¬ 
ligence  (DNI),  and  Department  of  Justice 
(DOJ). 


The  NIEM  program  has  committed  to  en¬ 
suring  that  future  versions  of  NIEM  will  be 
compatible  with  UCore.  UCore  has  been 
designed  to  be  interoperable  with  NIEM  so 
that  current  NIEM-based  systems  can  share 
information  via  UCore. 


The  MDA  vocabulary  will  be  an  integra¬ 
tion  of  MIEM,  as  the  maritime  extension  to 
NIEM,  and  UCore  products  and  services. 
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This  methodology  will  provide  common 
processes  and  guidelines  for  metadata  nam¬ 
ing  and  design  rules,  extending  the  MDA 
core  vocabulary,  and  registering  metadata 
assets. 

Standard  Data  Exchange  Methodology 

Current  data  exchange  initiatives  and  meth¬ 
odologies  employed  by  stakeholder  organi¬ 
zations  within  and  across  the  MDA  com¬ 
munity  have  created  a  web  of  terminology 
and  data  models  that  may  not  be  interopera¬ 
ble.  The  standardized  data  exchange  meth¬ 
odology  for  MDA  must  build  upon  and  ex¬ 
tend  established  methodologies,  processes, 
and  tools  from  MIEM,  NIEM,  and  UCore 
successes.  Recognizing  the  importance  of 
using  common  information  elements,  the 
interagency  community  has  begun  to  de¬ 
fine  a  UCore  model.  While  this  model  at¬ 
tempts  to  address  the  interoperability  issue, 
it  is  necessary  to  ensure  that  this  approach 
aligns  with  other  efforts  within  and  across 
the  maritime  community . 

Success  of  the  MDA  mission  relies  on  data 
exchange  capabilities  that  are  available, 
reliable,  secure,  and  easy  to  find  and  use. 
Support  mechanisms  need  to  be  in  place 
to  help  users  discover  and  access  authori¬ 
tative  sources  of  data,  understand  the  data. 
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and  select  the  items  they  need.  Capabilities 
and  resources  need  to  be  in  place  to  support 
data  and  information  sharing  operations  to 
include  the  tracking,  reporting,  and  man¬ 
agement  of  information  exchange  services 
and  their  associated  infrastructure. 

The  standardized  data  exchange  methodol¬ 
ogy  must  provide  common  processes  and 
guidelines,  and  a  consistent  set  of  tools  and 
services  to  enable  the  discovery  of  informa¬ 
tion  across  security  and  organizational  do¬ 
mains,  as  well  as  to  support  the  tagging  and 
marking  of  data  and  services.  The  goals  of 
this  approach  are  to  identify  best  practices 
for  establishing  standards  for  these  basic 
core  elements,  increase  the  unity  of  effort 
at  the  strategic  level,  define  cross-organiza¬ 
tional  standards  for  information  exchange, 
recommend  needed  governance  and  sup¬ 
port,  and  define  common  widely-accessi- 
ble  tools  to  support  information  exchange 
standards. 
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Information  Assurance  Strategy 


Information  Assurance  is  a  major  area  of 
focus  for  the  MDA  Architecture  Man¬ 
agement  Hub. 

An  acceptable  level  of  trust  is  critical  in  en¬ 
abling  an  information  sharing  environment 
involving  multiple  federal,  state,  tribal,  and 
other  sovereign  nation  organizations.  How¬ 
ever,  the  first  step  is  agreeing  to  standards 
that  all  participating  organizations  consider 
trustworthy  from  an  information  assurance 
standpoint;  i.e.,  the  information  systems  can 
be  trusted  with  the  appropriate  safeguards 
and  countermeasures  necessary  to  operate 
within  defined  levels  of  risk  to  organiza¬ 
tional  operations  and  assets,  individuals, 
or  other  organizations,  despite  the  possible 
environmental  disruptions,  human  errors, 
and  purposeful  attacks  that  may  occur.  To 
achieve  this  level  of  trust,  the  lA  processes 
within  this  net-centric  environment  must 
ensure  a  mutually  agreed  upon  acceptable 
level  of  confidentiality,  integrity,  availabil¬ 
ity,  and  authentication  of  the  information 
available.  Therefore,  the  foundation  of  the 
MDA  environment  must  have: 

•  The  ability  to  securely  exchange  infor¬ 
mation,  including  classified  and  sensi¬ 
tive  information,  as  well  as  intelligence 
and  law  enforcement  sensitive  data, 
across  multiple  security  domains. 

•  An  identity  management  solution  that  is 
shared,  standards-based,  and  recognized 
and  accepted  by  all  MDA  participants. 

•  Improved  and  standard  security  practic¬ 
es  across  the  MDA  environment. 


•  A  risk  management  framework  to  en¬ 
sure  that  information  assurance  security 
risks  are  addressed  appropriately. 

Cross-Domain  and  Multi-Level  Security 
Solutions 

There  will  be  users  within  the  MDA  en¬ 
vironment  who  may  not  have  a  security 
clearance  but  will  need  information  derived 
from  sources  that  may  be  highly  classified 
and  compartmentalized.  Such  informa¬ 
tion  must  first  be  sanitized  and  then  must 
be  able  to  move  throughout  the  MDA  envi¬ 
ronment.  Likewise,  personnel  working  on  a 
classified  network  need  to  be  able  to  access 
unclassified  information  in  order  to  form  a 
complete  operating  picture.  Safely  provid¬ 
ing  access  to  multiple  levels  of  information 
and  moving  information  between  classifi¬ 
cation  levels  or  organizational  domains  will 
require  trusted  solutions.  The  current  Cross 
Domain  Baseline  for  Distribution  produced 
by  the  Unified  Cross  Domain  Manage¬ 
ment  Office  (UCDMO)  will  be  leveraged 
to  achieve  this  requirement. 

Identity  Management  Solution 

Identity  management  provides  the  founda¬ 
tion  that  enables  implementation  of  a  need 
to  share  information  paradigm;  it  is  a  criti¬ 
cal  enabler  for  the  control  of  access  to  re¬ 
sources  in  a  fashion  that  balances  mission 
need  with  risk  to  resources.  The  Identity 
Management  solution  must  consider  the  re¬ 
quirement  of  a  multiple  security  domain  so¬ 
lution  and  enable  federated  services.  There 
are  three  key  components  to  such  a  solu¬ 
tion:  Identity  Proofing  when  credentials  are 
issued.  Identity  and  Credential  Authentica¬ 
tion  when  the  credentials  are  used,  and  Ac- 
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cess  Control  to  limit  the  user  to  appropriate 
access  and  actions. 

Identity  Proofing.  Identity  proofing  is  the 
keystone  to  the  credibility,  reliability,  and 
accuracy  of  the  overall  identity  manage¬ 
ment  process,  so  that  resultant  credentials 
are  bound  directly  to  the  actual  identity 
of  the  individual  requesting  them  when 
they  are  issued.  The  identity  management 
solution  must  be  able  to  support  multiple 
requirements  for  identity  proofing  (e.g., 
man-to-man,  man-to-machine,  and  ma- 
chine-to-machine  processes). 

Identity  and  Credential  Authentication. 
When  an  individual  asserts  an  identity 
claim  when  accessing  systems  or  servic¬ 
es,  an  identity  management  service  must 
authenticate  that  claim  through  the  use  of 


the  credential  issued  to  the  individual.  To 
achieve  that  goal,  the  credential  must  be 
authenticated.  Credential  authentication  is 
a  service  that  allows  any  entity  in  the  enter¬ 
prise  to  determine  that  a  trusted  credential 
has  not  been  forged,  has  not  expired,  and 
has  not  been  revoked  or  suspended.  It  has 
to  support  scalable  operations  with  reliable 
access  that  remains  accessible  and  robust 
in  the  face  of  cyber  attacks.  In  implement¬ 
ing  identity  and  credential  authentication, 
we  will  draw  upon  the  lessons  learned  from 
the  GM  Data  Sharing  Data  Sharing  Com¬ 
munity  of  Interest  (COI). 

Access  Control  (Authorization).  Critical  in 
a  net-centric  cross-agency  environment  is 
access  control-determining  when  a  user  is 
authorized  to  access  information,  systems, 
or  services.  All  MDA  users  require  immedi¬ 
ate  on-demand  access  to  the  range  of  prod¬ 
ucts  and  services  available  within  the  MDA 
environment,  regardless  of  the  organiza¬ 
tion  in  which  the  product  or  service  actu¬ 
ally  resides.  Therefore  the  MDA  data  shar¬ 
ing  environment  must  provide  support  for 
the  unanticipated  user-one  not  previously 
registered  or  enrolled  with  the  organization 
providing  services.  An  emerging  means  of 
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providing  this  support  in  a  net-centric  envi¬ 
ronment  is  through  Attribute-Based  Access 
Control  (ABAC).  This  approach  allows  de¬ 
cisions  concerning  access  to  information  to 
be  made  based  on  organizational  and  enter¬ 
prise  attributes  of  the  new  user,  rather  than 
on  prepared  classification  and  permission 
assignments.  ABAC  in  an  interagency  en¬ 
vironment  needs  to  be  supported  by  robust 
and  reliable  identity  management  and  attri¬ 
bute  services.  The  federated  identity  man¬ 
agement  service  must  provide  mutually 
trusted  authentication  of  identity  claims 
using  credentials  presented  by  the  unan¬ 
ticipated  user;  the  federated  attribute  man¬ 
agement  service  must  provide  accurate  at¬ 
tributes  bound  to  an  authenticated  identity 
at  the  enterprise  and  local  levels.  This  solu¬ 
tion  must  consider  not  only  the  attributes 
currently  available,  but  also  the  attributes 
that  may  be  needed  in  the  future.  We  will 
draw  extensively  on  the  lessons  learned 
from  the  Attribute  Based  Access  Control 
(ABAC)  pilot  that  the  MDA  Data  Sharing 
COI  is  currently  conducting,  and  several 
other  pilots  being  conducted  throughout 
the  DoD.  We  will  also  leverage  work  done 
by  the  Intelligence  Community  (IC)  DoD 
Attributes  and  Authorization  Tiger  Team  to 
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provide  a  starting  point  for  a  CONOPS  and 
standards. 

Improved  and  Standard  Security  Prac¬ 
tices  across  the  MDA  Environment 

To  share  information  among  different  or¬ 
ganizations,  there  must  be  mutual  trust  in 
all  participating  organizations’  information 
systems.  To  achieve  this  trust,  all  infor¬ 
mation  systems  must  be  certified,  accred¬ 
ited,  and  maintained  to  an  agreed  upon  set 
of  standards.  The  standards  for  acceptable 
risk  must  be  common  across  all  participat¬ 
ing  organizations.  Likewise,  the  risk  deter¬ 
mination  by  one  organization  for  its  data 
must  be  acceptable  by  any  other  organiza¬ 
tion  whose  data  may  reside  on  that  organi¬ 
zation’s  information  systems. 

Common  Set  of  Standards  for  Certifica¬ 
tion  and  Accreditation  (C&A)  Activities.  A 
common  set  of  C&A  standards  and  adher¬ 
ence  to  those  standards  are  critical  because 
these  are  the  basis  upon  which  trust  in  other 
organizations’  information  systems  is  es¬ 
tablished,  thus  allowing  unfettered  infor¬ 
mation  access.  This  is  especially  true  and 
critical  if  any  participating  organization 
uses  an  information  system  that  will  oper¬ 
ate  at  a  multi-level  security  (MLS)  mode. 
The  C&A  Transformation  Initiative,  a  joint 
DoD  and  DNI  CIO  effort  to  drastically 
streamline  the  C&A  process  for  national 
security  systems,  and  National  Institute  of 
Standards  and  Technology  (NIST)  Recom¬ 
mended  Security  Controls  for  Federal  In¬ 
formation  Systems  (SP800-53),  will  be  lev¬ 
eraged  to  achieve  this  requirement. 
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C&A  Reciprocity.  In  a  net-centric  infor¬ 
mation-sharing  environment,  reciprocity 
for  C&A  activities  across  all  participating 
organizations  is  critical.  Once  a  common 
set  of  security  standards  is  accepted  by  the 
participating  organizations,  the  first  step  is 
reciprocity  of  the  certifications  with  the  ul¬ 
timate  goal  of  having  reciprocity  for  both 
certifications  and  accreditations.  Again,  a 
joint  DoD  and  DNI  CIO  effort  to  drasti¬ 
cally  streamline  the  C&A  process  for  na¬ 
tional  security  systems  will  be  leveraged  to 
achieve  this  requirement. 

Controlled  Unclassified  Information  (CUI). 
Since  it  is  likely  that  much  of  the  informa¬ 
tion  in  the  MDA  environment  will  qual¬ 
ify  as  CUI  as  defined  by  reference  (1),  it 
is  necessary  that  participating  organiza¬ 
tions  control  and  mark  any  CUI  as  required 
by  reference  (1),  so  that  it  will  be  handled 
appropriately. 


Risk  Management  Framework 

The  risk  associated  with  information  shar¬ 
ing  among  MDA  participants  must  be  con¬ 
tinuously  mitigated  by  employing  a  Risk 
Management  Framework  (RMF).  The  RMF 
provides  GMCOI  members  with  a  disci¬ 
plined,  structured,  flexible,  extensible,  and 
repeatable  process  for  achieving  agreed- 
upon  degrees  of  trustworthiness  for  MDA 
information  systems.  The  RMF,  which  op¬ 
erates  within  the  context  of  the  architecture 
development  life  cycle,  can  be  applied  to 
both  new  and  legacy  information  systems 
that  are  part  of  the  MDA  environment.  The 
RMF  leverages  well-defined  information 
security  standards  and  guidelines  to  facil¬ 
itate  the  sharing  of  information  and  dem¬ 
onstrate  compliance  with  the  information 
security  requirements.  The  plug-and-play 
nature  of  the  RMF  allows  any  potential 
MDA  participant,  e.g.,  federal,  state,  local, 
and  tribal  governments,  private  sector  and 
international  partners  to  use  the  framework. 
The  RMF  being  developed  by  PM-ISE  will 
be  leveraged  to  develop  the  MDA  RMF. 

The  MDA  RMF: 

•  Embodies  the  basic  principles  of  infor¬ 
mation  security  -  confidentiality,  in¬ 
tegrity,  and  availability  -  so  that  MDA 
participating  organizations  are  assured 
that  the  information  they  provide  will 
be  protected  adequately. 

•  Is  integrated  with  the  MDA  Enterprise 
Architecture. 

•  Employs  information  security  standards 
and  guidance  developed  by  the  NIST, 
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Organizational  View 

Architecture  Description 

Organizational  Inputs 

EA  Reference  Models 

Laws,  Directives,  Policy  Guidelines 

Segment  and  Solution  Architectures 

MDA  Strategic  Goals,  Objectives  and  Priorities 

Mission  and  Business  Processes 

MDA  Participants'  Priorities  and  Resource  Availability 

Information  System  Boundaries 

Supply  Chain  Considerations 

Business  Context 


Monitor 

Security  State 
SP  800-37  /  SP  800-53A 


Categorize 

Information  Systems 
FIPS  1 99 /SP  800-60 


Risk  Management 
Framework 


Select 

Security  Controls 
FIPS  200 /SP  800-53 

Security  Plan 


Authorize 

Information  Systems 
SP  800-37 

Authority  to  Operate  (ATO) 


Security  Life  Cycle 


Assess 

Security  Controls 
SP  800-53A 


Security  Assessment  Report 


Implement 

Security  Controls 
SP  800-70 


MDA  Information  Assurance  Risk  Management  Framework 


and  builds  on  the  foundation  of  trast  be¬ 
tween  the  DoD  and  IC. 

The  MDA  RMF  consists  of  the  following 
steps,  as  illustrated  by  the  figure  above, 
with  the  NIST  security  standards  and  guide¬ 
lines  associated  with  each  activity  for  risk 
management. 

Step  1.  Categorize  the  MDA  information 
systems  and  information  residing  within 
the  systems  based  on  the  security  category 
recommendations  from  the  appropriate  In¬ 
formation  Security  governance  functions. 
This  categorization  must  consider  the  po¬ 
tential  impact  of  limiting  access  to  the  in- 
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formation,  as  well  as  potential  impacts  if 
the  information  is  shared.  The  business 
context  that  consists  of  the  applicable  laws, 
directives,  and  policy  guidelines  as  well  as 
MDA  strategic  goals,  objectives,  and  prior¬ 
ities  must  also  be  considered.  The  risks  as¬ 
sociated  with  each  category  must  be  identi¬ 
fied  and  prioritized. 

Step  2.  Select,  supplement,  and  docu¬ 
ment  safeguards  and  countermeasures. 

•  Select  an  agreed  upon  set  of  safeguards 
and  countermeasures  for  MDA  infor¬ 
mation  systems  based  on  the  prioritized 
technical  risks,  security  categorizations. 
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and  recommendations  from  the  MDA 
security  governance  functions. 

•  Supplement  the  agreed  upon  set  of  safe¬ 
guards  and  countermeasures  based  on 
an  assessment  of  the  MDA  participant’s 
site  specific  risk  conditions,  includ¬ 
ing  organizational-specific  security  re¬ 
quirements,  specific  and  credible  threat 
information,  cost-benefit  analyses,  and 
special  circumstances. 

•  Document  the  set  of  safeguards  and 
countermeasures  in  the  MDA  informa¬ 
tion  system  security  plan,  including 
the  rationale  for  any  refinements  and 
adjustments  to  the  implemented  set  of 
safeguards  and  countermeasures  based 
on  MDA  participants’  site-specific 
conditions. 

Step  3.  Implement  the  set  of  safeguards 
and  countermeasures  in  the  MDA  informa¬ 
tion  systems. 

Step  4.  Assess  the  safeguards  and  coun¬ 
termeasures  using  appropriate  methods  to 
determine  the  extent  to  which  they  are  im¬ 
plemented  correctly,  operate  as  intended, 
and  produce  the  desired  outcome  with  re¬ 
spect  to  meeting  the  security  requirements 
of  the  MDA  information  system.  This  step 
is  key  to  demonstrating  the  degree  of  trust¬ 
worthiness  of  the  system,  a  critical  input  to 
the  risk  decision  and  maintenance  of  trust 
within  the  MDA  environment.  The  assess¬ 
ment  will  be  documented  in  the  Security 
Assessment  Report. 


Step  5.  Authorize  the  information  sys¬ 
tem  operation  with  the  implemented  safe¬ 
guards  and  countermeasures  based  upon  a 
determination  that  the  risk  to  MDA  partici¬ 
pants’  operations  and  assets,  is  acceptable. 
This  step  results  in  an  Authority  to  Operate 
(ATO)  for  this  particular  MDA  information 
system. 

Step  6.  Monitor  and  assess  the  document¬ 
ed  and  agreed  upon  set  of  safeguards  and 
countermeasures  in  all  MDA  information 
systems  on  a  continual  basis.  Document 
any  changes  to  information  systems,  con¬ 
duct  security  impact  analyses  of  the  associ¬ 
ated  changes,  and  report  the  security  status 
of  the  information  systems  to  appropriate 
MDA  officials  on  a  regular  basis. 
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Resource  Strategy 


Resources  dedicated  to  accomplish¬ 
ing  the  goal  of  a  net-centric,  informa¬ 
tion  sharing  environment  as  outlined  in 
this  document,  will  be  applied  toward  two 
complementary  efforts.  First,  resources  are 
needed  to  design  and  develop  the  MDA  en¬ 
terprise  architecture.  Second,  departments 
and  agencies,  guided  by  the  architecture, 
will  invest  resources  in  a  manner  that  will 
increase  information  sharing  and  lead  to 
greater  levels  of  MDA. 


As  the  architecture  is  designed,  budget  au¬ 
thorities  will  gain  a  better  understanding  of 
the  magnitude  of  the  resource  requirements 
necessary  to  implement  capabilities  to  sup¬ 
port  MDA.  The  MDA  enterprise  architec¬ 
ture  will  act  as  guidance  for  investments 
which  can  contribute  to  MDA,  and  assist 
departments  and  agencies  in  their  efforts  to 
address  the  capability  gaps  highlighted  in 
the  Interagency  Investment  Strategy.  The 
architecture  will  focus  those  efforts,  help 


Designing  an  effective  architecture  to  be 
utilized  by  the  entire  GMCOI  will  require 
an  investment  of  time  and  expertise  from 
departments  and  agencies  throughout  the 
Federal  Government.  To  be  successful,  de¬ 
partments  and  agencies  must  be  willing  to 
contribute  knowledgeable  individuals  to  par¬ 
ticipate  in  the  MDA  Architecture  Manage¬ 
ment  Hub  focus  teams.  These  focus  teams 
will  set  priorities  and  develop  the  standards 
and  processes  that  will  lead  to  a  federated 
information  sharing  environment. 


ensure  interoperability,  and  prevent  un¬ 
necessary  redundancy.  As  segments  of  the 
MDA  enterprise  architecture  are  designed, 
members  of  the  GMCOI  can  use  the  stan¬ 
dards  and  processes  developed  to  inform 
their  acquisition  plans.  Design  of  the  archi¬ 
tecture  will  leverage  existing  and  emergent 
infrastructure,  systems,  services,  and  other 
initiatives.  Therefore,  much  of  the  cost  will 
be  borne  by  those  efforts. 
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Summary 


As  the  lead  for  the  MDA  Architecture 
Management  Hub,  the  DON  CIO  will 
follow  the  strategy  outlined  in  this  document 
to  design  an  actionable  MDA  enterprise 
architecture  that  can  guide  implementa¬ 
tion  efforts  to  achieve  a  secure,  collabora¬ 
tive  information  sharing  environment  for 
the  GMCOI.  This  architecture  will  build 
on  the  work  of  other  organizations  within 
the  Federal  Government  and  draw  upon  the 
expertise  of  individuals  from  those  organi¬ 
zations.  Working  within  the  governance 
structure  created  by  the  MDA  CONOPS, 
the  Architecture  Management  Hub  will  de¬ 
velop  a  set  of  complementary  architectural 
models.  These  models  will  constitute  the 
core  of  an  “as-is”  and  “to-be”  MDA  Enter¬ 
prise  Architecture.  They  will  serve  as  the 
basis  for  development  of  an  architecture 
migration  and  implementation  plan. 

By  following  this  document’s  data  strategy, 
the  resulting  architecture  will  provide  data 
and  information  exchange  standards  that 
permit  organizations  to  publish  informa¬ 
tion  for  use  by  authorized  users.  The  MDA 


Architecture  Management  Hub  will  also 
recommend  standard  solutions  for  sharing 
information  across  security  domains,  when 
authorized  and  appropriate,  and  for  control¬ 
ling  information  access. 

Strategy  implementation  will  follow  an  it¬ 
erative  process,  beginning  with  agencies 
and  departments  within  the  Federal  Gov¬ 
ernment  and  adding  products  and  services 
over  time.  Once  this  process  is  in  place  and 
functioning,  representative  organizations 
from  state,  local,  and  tribal  governments, 
as  well  as  appropriate  representatives  from 
the  private  sector  and  international  organi¬ 
zations  will  be  invited  to  participate. 

The  work  of  the  MDA  Architecture  Man¬ 
agement  Hub  will  extend  well  beyond  the 
GMCOI.  The  information  sharing  stan¬ 
dards  and  methods  developed  for  MDA 
will  have  application  throughout  the  Feder¬ 
al  Government  and  beyond.  The  processes 
and  methodologies  developed  by  this  effort 
can  benefit  COIs  and  organizations  facing 
similar  information  challenges. 
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Guidance  for  MDA  information  sharing  is  de¬ 
rived  from  the  following  documents: 

A.  National  Plan  to  Achieve  Maritime  Domain 
Awareness  for  the  National  Strategy  for 
Maritime  Security,  October  2005 

B.  Global  Maritime  Intelligence  Integration 
Plan  for  the  National  Strategy  for  Maritime 
Security,  October  2005 

C.  National  Concept  of  Operations  for  Mari¬ 
time  Domain  Awareness,  December  2007 

D.  National  Maritime  Domain  Awareness  In¬ 
teragency  Investment  Strategy,  May  2007 

E.  MDA  Interagency  Requirements  Analysis 
(lARA) 

F.  National  MDA  Study  Inter-agency  Needs 
Analysis  (lANA),  December  21, 2006 

G.  MDA  Interagency  Capabilities  Document, 
Version  2.0.3,  31  January  2007  (lACD) 

H.  MDA  Interagency  Core  Architecture  Docu¬ 
ment  (lACA),  Draft  Version  1 .2,  February 
08,  2007 

I.  National  Strategy  for  Information  Sharing, 
October  2007 

J.  Information  Sharing  Environment  Enter¬ 
prise  Architecture  Framework,  v.1,  August 
2007 

K.  Executive  Order  13388,  Further  Strength¬ 
ening  the  Sharing  of  Terrorism  Information 
to  Protect  Americans,  October  25,  2005 

L.  Presidential  Memorandum,  Subj:  Designa¬ 
tion  and  Sharing  of  Controlled  Unclassified 
Information  (CUI),  May  9,  2008 
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M.  NIEM  Program  Management  Office,  In¬ 
troduction  to  the  National  Information  Ex¬ 
change  Model  (NIEM),  version  0.3,  Febru¬ 
ary  12,  2007  (available  at  http://www.niem. 
gov/files/N  IEM_lntroduction.pdf) 

N.  United  States  Intelligence  Community  In¬ 
formation  Sharing  Strategy,  February  22, 
2008 

O.  Department  of  Homeland  Security  Informa¬ 
tion  Sharing  Strategy,  April  18  2008 

P.  DoD  Information  Sharing  Strategy,  May  4, 
2007 

Q.  DoD  Directive  8500.01  E,  Information  As¬ 
surance  (lA),  October  24,  2002 

R.  DoD  Net-Centric  Data  Strategy,  May  9, 
2003 

S.  DoD  Directive  8320.02,  Data  Sharing  in  a 
Net-Centric  Department  of  Defense,  De¬ 
cember  2,  2004. 

T.  FIPS  PUB  201-1:  Personal  Identity  Veri¬ 
fication  (PIV)  of  Federal  Employees  and 
Contractors 

U.  National  Maritime  Intelligence  Center 
(NMIC)  Integrated  Maritime  Intelligence  Ar¬ 
chitecture  (IMA)Transformation  Strategy, 
Release  Version  1.1  ,01  March  2007 
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Acronyms 


ABAC 

Attribute  Based  Access  Control 

AIS 

Automatic  Identification  System 

C&A 

Certification  and  Accreditation 

CES 

Core  Enterprise  Services 

CBP 

Customs  and  Border  Protection 

COI 

Community  of  Interest 

CONORS 

Concept  of  Operations 

CUI 

Controlled  Unclassified  Information 

DNI 

Director  of  National  Intelligence 

DoD 

Department  of  Defense 

DoDAF 

DoD  Architecture  Framework 

DON 

Department  of  the  Navy 

DON  CIO 

Department  of  the  Navy  Chief  Information  Officer 

DS  COI 

Data  Sharing  Community  of  Interest 

FEA 

Federal  Enterprise  Architecture 

FSAM 

Federal  Segment  Architecture  Methodology 

OMAN 

Global  Maritime  and  Air  Intelligence  Integration 

GMCOI 

Global  Maritime  Community  of  Interest 

GMSA 

Global  Maritime  Situation  Awareness 

lA 

Information  Assurance 

lACA 

Interagency  Core  Architecture  Document 

1C 

Intelligence  Community 

IMA 

Integrated  Maritime  Intelligence  Architecture 

lOOS 

Integrated  Ocean  Observing  System 

ISE 

Information  Sharing  Environment 

ISE  EAF 

Information  Sharing  Environment  Enterprise  Architecture  Framework 

ISSC 

Information  Sharing  Sub  Committee 

IT 

Information  Technology 

MDA 

Maritime  Domain  Awareness 

MIEM 

Maritime  Information  Exchange  Model 

MLS 

Multi  Level  Security 

NIEM 

National  Information  Exchange  Model 

NIST 

National  Institute  of  Standards  and  Technology 

NOAA 

National  Oceanographic  and  Atmospheric  Administration 

PM 

Personally  Identifiable  Information 

SME 

Subject  Matter  Experts 

SOA 

Service  Oriented  Architecture 

Ucore 

Universal  Core 
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To  view  online,  download,  or  request  a  copy  of  this  strategy  please  visit  www.doncio.navy.mil 
For  more  information  about  this  strategy,  please  contact  DON  CIO  at  (703)  607-5608 


